One of the most common sales mantras is “know your customer.” This basic tenet of selling has grown far beyond knowing who enters the store; it requires among other things, knowing what attracts customers, what they look at, how they move around the store, and how long they stay. By studying customer buying habits, retailers have been able to maximize their revenues through tailoring their promotions, offerings and even store layouts to suit their customers' preferences and habits.
For bricks-and-mortar sellers of goods and services, gathering such data rapidly becomes cost-prohibitive. Identifying basic information about customer behavior at the check-out stand may be fairly cost-effective; but monitoring a customer's path through the store or how long customers spend selecting a particular product requires much more expensive monitoring. In contrast, such behavioral tracking in the on-line environment occurs without significant increases in cost, thus making complex data collection not only possible, but a requirement to remain competitive.
In the on-line environment, customer behavior may be tracked by the website server containing the website visited by the customer, or by another server, such as a remote data collector, which may be remotely located. The data collector is notified of activity on a website so that it can monitor and track the activity. One method of achieving this notification is through the use of a request for embedded content.
Embedded content is part of a web page, such as an image, that is requested as a separate file from the file containing the web page. The separate file may be requested from the server containing the website or from a remote server, such as a remote content server or data collection server. For example, when a user requests a web page from a website server, the website server sends the web page file to the user's client. The client, such as a web browser, then attempts to render the file as a viewable web page. However, upon rendering the web page file, the client may find a reference to a separate file located on the website server or a remote server. After the content is located and sent to the client, the client renders the separate file containing the embedded content along with the original web page.
A web bug is a particular type of embedded content where the content itself is irrelevant, but the request for content carries useful information. For example, a web bug is often a 1 pixel by 1 pixel, clear image. This image is small enough to appear invisible to the user. When the client encounters the web bug code upon rendering a web page, the client sends the request and additional information about the user and the user's environment to the server indicated by the web bug code. The request can include the data from a cookie, or other information gathered as a result of the execution of a script that occurred when the web page was rendered. Where the server indicated by the web bug code is a data collection server, the data collection server may set an additional cookie for identification for tracking purposes. In this manner, the web bug request can be used to indicate to a data collection server that a particular web page is being rendered.
One method for including the request is to write the request as a static image tag in Hyper Text Markup Language (HTML). The following is an example of an image tag in HTML:                <imgsrc=“http://ad.datacollectionserver.com/tracker.exe?AID=14658&PID=259294&banner=0.gif”width=1height=1border=0>Here, the term “ad.datacollectionserver.com” refers to the address of the data collector.        
Another common method of including the request is to use a scripting language, such as JavaScript. One advantage of using a script instead of a static image tag is that the script can perform other functions including gathering additional data and sending it along with the request. In either case, the result is a request sent to the data collection server upon the occurrence of an event, such as the loading and rendering of a web page. Once the request has been sent to the data collector, the data collector can begin performing tracking functions.
This common method suffers from several significant drawbacks. Existing data collection systems generally use a set of predefined events. A data collection system provider may create a set of web bug requests that a website operator can paste in web pages on the website. These web bug requests have been created by the data collection system provider to identify specific events, such as the opening of a home web page or a check-out page. These events are coded in the web bug request itself, or in an environment variable that is sent to the data collector along with the request. The website operator, however, cannot change the event identified in the web bug request without having the data collection system provider to modify the data collection system receiving the requests.
In many cases, the predefined events of the data collection system may not accurately identify the events a website operator would like to track. For example, an auction website operator may want to track every time a bid is placed. But the data collector may not have a predefined event describing such an action. The auction website operator may use a predefined event, such as a page load event, if that predefined event occurs when a bid is actually placed. Even with this approach, the event identified in the web bug request may not identify “Bids Placed,” but rather, may indicate “Page Load.”
The predefined nature of this approach limits the flexibility of web operators to accurately describe events to be tracked. The auction website operator could use some predefined event such as product page view for indicating when a bid is placed, if the bid causes a new page to be requested. But the event would not accurately describe the bid event and may be confused with other data tracking product page events. Such an approach does not lend itself well to all websites.
Similarly, the auction website operator may want to record other data about the bid environment when the bid was placed. For example, the website operator may want to track the bid amount, the time of the bid, the increase over the last bid, and other attributes. Such customization is generally impossible or extremely difficult using existing data collection systems.
Furthermore, in existing data collection systems, when the website operator wishes to change an event or the data sent to the data collection server upon the occurrence of an event, the operator must normally contact a data collection server administrator. The data collection server administrator modifies the configuration of the data collection server to collect and process the custom event or data. Then, the data collection server administrator makes changes to the code that contacts the data collection server; either the website operator or the data collection server administrator then inserts the new code into the web page. Because the website operator must enlist the aid of the data collection server administrator, these changes are costly and inefficient. The problem is further exacerbated when multiple changes to multiple web pages and websites are required.
What is needed is a system or method wherein the website operator can design and implement events that more carefully match the website. What is further needed is a system wherein the website-operator is able to select data to send to the data collection server, and to make changes at random, without the assistance of the data collection server administrator. A system or method that would allow the efficient customization and modification of the tracking events and data would be of great value to website operators.